Summary

A $gt/$lt range bound that lies entirely outside the indexed field's schema minimum/maximum silently drops the boundary document. The out-of-range bound is clamped to the boundary when the index string is built (getNumberIndexString), but the bound stays exclusive — so the boundary document is excluded. Storages that resolve the query purely from the index (selectorSatisfiedByIndex: true — memory, localstorage, foundationdb, denokv) return wrong results with no error and no matcher fallback.

Reproduce

Field score with { minimum: 0, maximum: 100 }, docs score ∈ {0, 1, 50, 99, 100}:

{ score: { $gt: -10 } }  → [1, 50, 99, 100]   // drops score=0  (expected all 5)
{ score: { $lt: 110 } }  → [0, 1, 50, 99]     // drops score=100 (expected all 5)

$gte: -10 / $lte: 110 are unaffected, because the inclusive bound includes the clamped boundary — which is why this slipped through (the existing boundary test only checks bounds at the limit, not beyond it).

Fix

In the query planner, a lower bound below the field minimum becomes INDEX_MIN (inclusive) and an upper bound above the field maximum becomes INDEX_MAX (inclusive). Exact-boundary exclusives ($gt at the minimum, $lt at the maximum) and all in-range bounds are unchanged.

Tests

Adds a rx-storage-query-correctness case covering both bug cases plus regression guards ($gt at minimum still excludes it, $lt at maximum still excludes it, in-range bounds unchanged). Validated end-to-end against the memory storage before/after the fix.